home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / ALL95.LZH / transcript_1003 / text0009.txt < prev    next >
Encoding:
Text File  |  1995-10-04  |  3.3 KB  |  78 lines
  1. > Instead of adressing a structure in 68030, I think I would take less machine time
  2. > adressing each array lonely. I explain :
  3.  
  4. I beg to differ, but we'll get to that.
  5.  
  6. > with a structure array like :
  7. ...
  8. > To use code like a[1], then a[2], then a[3], you must increase your register
  9. > pointer An before a read.
  10.  
  11. Yes.
  12.  
  13. > If I code
  14. > short a[40]
  15. > short b[40] , and so on, I can put a register = first value of the array,
  16. > then I use (an)+ mode. With that, code can improve a lot when there are lots
  17. > of structure manipulations. I don't know if it speeds c code a lot, coz I'm not
  18. > sure a c compiler use (An)+ options. 
  19.  
  20. C compilers (at least the good ones) use those addressing modes when they
  21. can. They never break structures apart, though, and there are good reasons
  22. for that.
  23.  
  24. > If you don't understand what I try to explain, don't worry, keep the structures,
  25. > I'll adapt for 68030. Anyway, I'll break all the structures.
  26.  
  27. Please, don't do that. Apart from making the assembly parts impossible to
  28. use together with the C parts, it'll also cause slow down in most places.
  29.  
  30. On processors with data caches like the '030 it's a good idea to keep
  31. frequently used data close together, since the cache is usually filled in
  32. bursts of 16 bytes (or something like that). In the case of an array of
  33. a structure, that means that a complete structure element is often loaded
  34. at once. Since you often access several of the individual elements in the
  35. structure element the processor won't need to go out and fetch anything
  36. else from memory. If the individual elements were in different places a
  37. simple thing like:
  38.   if ((my_array[i].x > my_array[i].y) && (my_array[i].top == my_array[i].bot))
  39. would end up loading _64_ bytes from memory. If the structure was kept
  40. together only a single cache line (16 bytes) would have to be read.
  41.  
  42. _If_ there are lots of sequential accesses to a structure it might be
  43. a good idea to do as you suggest, but in DVIEW there are very few of
  44. those (for the structures loaded from the WAD that is).
  45.  
  46. Let me know if you disagree with this. Apart from the reasons above, the
  47. future plans of moving this onto the DSP would probably also make it
  48. necessary to put the structures back together since that chip has far
  49. too few address registers to waste.
  50.  
  51. > Does it mean that also it's not used, except for player start pos, I must code it ?
  52. > I think it might give the monsters and objects positions in the game, but I may be
  53. > wrong. Correct me if I'm wrong.
  54.  
  55. Yes, I believe monsters, weapons, medikits etc etc are in there, so it's
  56. definitely needed.
  57.  
  58. > > I still don't like your name for it, though.
  59. > 
  60. > So, I'll call it the 'don't cross this wall' function :-)
  61.  
  62. That's better. When I've written it we won't have to call it anything
  63. anymore, which is even better.  ;-)
  64.  
  65.  
  66. By the way, why did you convert the WAD load routines to assembler?
  67. 10 lines of assembler could've got 99% of the speed with _much_ less work.
  68. Then there's the question of whether there's any point in optimizing
  69. a routine that's used at most once every fifteen minutes or so.
  70. C is also very good at taking care of the ARGV stuff.
  71.  
  72. -- 
  73.   Chalmers University   | Why are these |  e-mail:   d8klojo@dtek.chalmers.se
  74.      of Technology      |  .signatures  |            rand@cd.chalmers.se
  75.                         | so hard to do |  www/ftp:  rand.thn.htu.se
  76.    Gothenburg, Sweden   |     well?     |            (MGIFv5 and QLem)
  77.  
  78.